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Abstract.  In  this  paper  we  present  an  integrated  formal  framework  for 
the  specification  and  analysis  of  Multi- Agent  Systems  (MAS).  Agents  are 
specified  in  a  synchronous  programming  language  called  Secure  Opera¬ 
tions  Language  (SOL)  which  supports  the  modular  development  of  secure 
agents.  Multi-agent  systems  are  constructed  from  individual  agent  mod¬ 
ules  by  using  the  composition  operator  of  SOL,  the  semantics  of  which 
are  guaranteed  to  preserve  certain  individual  agent  properties.  The  for¬ 
mal  semantics  and  the  underlying  framework  of  SOL  also  serve  as  the 
basis  for  analysis  and  transformation  techniques  such  as  abstraction, 
consistency  checking,  verification  by  model  checking  or  theorem  proving, 
and  automatic  synthesis  of  agent  code.  Based  on  this  framework,  we  are 
currently  developing  a  suite  of  analysis  and  transformation  tools  for  the 
formal  specification,  analysis,  and  synthesis  of  multi-agent  systems. 


1  Introduction 

Building  trusted  applications  is  hard,  especially  in  a  distributed  or  mobile  set¬ 
ting.  Existing  methods  and  tools  are  inadequate  to  deal  with  the  multitude  of 
challenges  posed  by  distributed  application  development.  The  problem  is  exac¬ 
erbated  in  a  hostile  environment  such  as  the  Internet  where,  in  addition,  ap¬ 
plications  are  vulnerable  to  malicious  attacks.  It  is  widely  acknowledged  that 
intelligent  software  agents  provide  the  right  paradigm  for  developing  agile,  re- 
configurable,  and  efficient  distributed  applications.  Distributed  processing  in 
general  carries  with  it  risks  such  as  denial  of  service,  Trojan  horses,  informa¬ 
tion  leaks,  and  malicious  code.  Agent  technology,  by  introducing  autonomy  and 
code  mobility,  may  exacerbate  some  of  these  problems.  In  particular,  a  malicious 
agent  could  do  serious  damage  to  an  unprotected  host,  and  malicious  hosts  could 
damage  agents  or  corrupt  agent  data. 

Secure  Infrastructure  for  Networked  Systems  (SINS)  being  developed  at  the 
Naval  Research  Laboratory  is  a  middleware  for  secure  agents  intended  to  provide 
the  required  degree  of  trust  for  mobile  agents,  in  addition  to  ensuring  their 
compliance  with  a  set  of  enforceable  security  policies.  An  infrastructure  such  as 
SINS  is  central  to  the  successful  deployment  and  transfer  of  distributed  agent 
technology  to  Industry  because  security  is  a  necessary  prerequisite  for  distributed 
computing. 
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2  SINS  Architecture 


Figure  1  shows  the  architecture  of  SINS.  Agents  are  created  in  a  special  purpose 
synchronous  programming  language  called  Secure  Operations  Language  (SOL) 
[5-7].  A  SOL  application  comprises  a  set  of  agent  modules,  each  of  which  runs 
on  an  Agent  Interpreter  (AI).  The  AI  executes  the  module  on  a  given  host  in 
compliance  with  a  set  of  locally  enforced  security  policies.  A  SOL  multi-agent 
system  may  run  on  one  or  more  AIs,  spanning  multiple  hosts  across  multiple  ad¬ 
ministrative  domains.  Agent  Interpreters  communicate  among  themselves  using 
an  inter-agent  protocol  [18],  similar  to  SOAP/XML  [19]. 

3  A  Brief  Introduction  to  SOL 

A  module  is  the  unit  of  specification  in  SOL  and  comprises  variable  declarations, 
assumptions  and  guarantees,  and  definitions.  The  assumptions  section  includes 
assumptions  about  the  environment  of  the  agent.  Execution  aborts  when  any  of 
these  assumptions  are  violated  by  the  environment.  The  required  safety  prop¬ 
erties  of  an  agent  are  specified  in  the  guarantees  section.  The  definitions 
section  specifies  updates  to  internal  and  controlled  variables  as  functions  (or 
more  generally  as  relations).  A  SOL  module  describes  the  required  relation  be¬ 
tween  monitored  variables ,  variables  in  the  environment  that  the  agent  monitors, 
and  controlled  variables ,  variables  in  the  environment  that  the  agent  controls. 
Additional  internal  variables  are  often  introduced  to  make  the  description  of  the 
agent  concise.  In  this  paper,  we  only  distinguish  between  monitored  variables, 
i.e.,  variables  whose  values  are  specified  by  the  environment,  and  dependent  vari¬ 
ables,  i.e.,  variables  whose  values  depend  on  the  values  of  monitored  variables. 
Dependent  variables  include  all  the  controlled  variables  and  internal  variables  of 
an  agent  module. 

3.1  Events 

SOL  borrows  from  SCR  the  notion  of  events  [13].  Informally,  an  SCR  event 
denotes  a  change  of  state,  i.e.,  an  event  is  said  to  occur  when  a  state  variable 


Fig.  1.  Architecture  of  SINS. 
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changes  value.  SCR  systems  are  event-driven  and  the  SCR  model  includes  a 
special  notation  for  denoting  them.  The  notation  @T(c)  denotes  the  event  “con¬ 
dition  c  became  true”,  @F(c)  denotes  “condition  c  became  false”  and  @C(x) 
the  event  “the  value  of  expression  x  has  changed” .  These  constructs  are  defined 
formally  below.  In  the  sequel,  PREV  (x)  denotes  the  value  of  expression  x  in  the 
previous  state. 

@T(c)  d=  -iPREV(c)  A  c 
OF (c)  d=  PREV(c)  A -ic 
0C(c)  =f  PREV(c)  ±  c 

Events  may  be  triggered  predicated  upon  a  condition  by  including  a  “when” 
clause.  Informally,  the  expression  following  the  keyword  when  is  “aged”  (i.e., 
evaluated  in  the  previous  state)  and  the  event  occurs  only  when  this  expression 
has  evaluated  to  true.  Formally,  a  conditioned  event,  defined  as 

OT(c)  when  d  d=  -iPREV(c)  A  c  A  PREV(d), 

denotes  the  event  “condition  c  became  true  when  condition  d  was  true  in  the 
previous  state” .  Conditioned  events  involving  the  two  other  event  constructs  are 
defined  along  similar  lines. 

In  SOL  we  extend  the  SCR  event  construct  to  include  events  that  are  trig¬ 
gered  by  the  invocation  of  a  method  (i.e.,  a  procedure  or  function  call)  of  the 
embedding  language.  For  example,  the  event  associated  with  the  invocation  of 
method  push(x)  of  a  stack  is  denoted  as  Opush.  This  provides  users  the  ability 
to  implement  security  automata,  a  special  class  of  Biichi  automata  that  accept 
safety  properties  [1, 17]. 


3.2  Definitions 

A  variable  definition  is  either  a  one-state  or  a  two-state  definition.  A  one-state 
definition,  of  the  form  x  =  expr  (where  expr  is  an  expression),  defines  the  value 
of  variable  x  in  terms  of  the  values  of  other  variables  in  the  same  state.  A  two- 
state  variable  definition,  of  the  form  x  =  initially  init  then  expr  (where 
expr  is  a  two-state  expression),  requires  the  initial  value  of  x  to  equal  expres¬ 
sion  init ;  the  value  of  x  in  each  subsequent  state  is  determined  in  terms  of  the 
values  of  variables  in  that  state  as  well  as  the  previous  state  (specified  using 
operator  PREV  or  by  a  when  clause).  A  conditional  expression,  consisting  of  a 
sequence  of  branches  “  []  guard  — »  expression” ,  is  introduced  by  the  keyword 
“if”  and  enclosed  in  braces  ("{"  and  "}").  A  guard  is  a  boolean  expression.  The 
semantics  of  the  conditional  expression  if  {  \\gi  — »  exprx  []g2  — >■  expr2  ...  }  is 
defined  along  the  lines  of  Dijkstra’s  guarded  commands  [10]  -  in  a  given  state, 
its  value  is  equivalent  to  expression  expVi  whose  associated  guard  g\  is  true.  If 
more  than  one  guard  is  true,  the  expression  is  nondeterministic.  It  is  an  error  if 
none  of  the  guards  evaluates  to  true,  and  execution  aborts.  The  case  expression 
case  expr  {  []iq  — >-  exprx  []i>2  — >-  expr2  ...  }  is  equivalent  to  the  conditional 
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deterministic  reactive  enforcement  module 
safestack (integer  max_depth)  { 

//  assumption:  max_depth  >  0 
interfaces 

void  push(integer  x) ; 

void  pop  ()  ; 

integer  top(); 
internal  variables 

{empty,  nonempty}  status; 
integer  in  [0:max_depth]  depth; 
guarantees 
INV1  = 

(status  ==  empty)  <=>  (depth  ==  0) ; 
definitions 

[status,  depth]  =  initially  [empty,  0]  then 
case  PREV(status)  { 

[]  empty  -> 
if  { 

[]  @push  ->  [nonempty,  PREV (depth)  +  1] 

//  other  operations  illegal! 

} 

[]  nonempty  -> 
if  { 

[]  Otop  -> 

[PREV (status) ,  PREV (depth)] 

[]  @pop  when  (depth  >  1)  -> 

[nonempty ,  PREV (depth)  -  1] 

[]  @pop  when  (depth  ==  1)  -> 

[empty ,  0] 

[]  @push  when  (depth<max_depth)  -> 

[nonempty ,  PREV (depth)  +  1] 

//  @push  when  (depth  ==  max_depth)  illegal! 

} 

};  //  end  case 
}  //  end  module  safestack 

Fig.  2.  Agent  module  for  safestack. 

expression  if  {  [ }(expr  ==  Vi)  — >  exp^  \\(expr  ==  Vo)  — t  expr2  . . .  }.  The  con¬ 
ditional  expression  and  the  case  expression  may  optionally  have  an  otherwise 
clause  with  the  obvious  meaning. 


3.3  An  Example:  Safety  Policy  Enforcement 

We  examine  how  SOL  agents  are  used  to  enforce  safety  policies  on  a  given 
agent  interpreter.  The  example  we  shall  use  is  a  stack,  which  has  the  associated 
methods  push,  pop,  and  top.  Informally,  push(x)  pushes  the  value  of  integer 
variable  x  on  the  stack  and  pop()  pops  the  topmost  value  off  the  stack.  The 
method  top()  returns  the  current  value  at  the  top  of  the  stack  and  leaves  the 
stack  unchanged.  The  stack  can  accommodate  at  most  max_depth  items.  We 
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deterministic  reactive  enforcement  module  SecureRead  { 


interfaces 

string  f ile_read (string  filename,  integer  position,  integer  size); 
void  send(string  address,  string  data); 

internal  variables 

{no_reads,  read_perf ormed}  status; 

definitions 

status  =  initially  no_reads  then 
case  PREV(status)  { 

[]  no_reads  -> 
if  { 

[]  @send  ->  PREV(status) 

[]  <§file_read  ->  read_performed 

} 

[]  read_performed  -> 
if  { 

[]  @file_read  ->  read_performed 
//  Osend  illegal! 

> 

};  //  end  case 
}  //  end  module  SecureRead 

Fig.  3.  A  SOL  module  that  enforces  safe  access  to  local  files. 


assume  that  other  agents  (not  shown)  access  the  stack  by  invoking  its  methods. 
The  safety  policies  we  wish  to  enforce  are:  (i)  No  more  than  max_depth  items 
are  pushed  on  the  stack,  (ii)  Invocations  of  methods  top  and  pop  are  disallowed 
on  an  empty  stack.  Figure  2  shows  a  SOL  enforcement  agent  safestack  which 
enforces  these  safety  policies  on  all  other  SOL  agents  which  use  the  stack  object 
(implemented  in  the  embedding  language).  Note  that  by  deliberately  omitting 
the  otherwise  clauses  in  the  if  statements,  we  abort  the  execution  of  a  SOL 
agent  when  none  of  the  guards  is  true  during  execution.  If  this  is  too  drastic, 
corrective  action  may  be  specified  in  an  otherwise  clause;  for  example,  to  ignore 
all  push  actions  when  the  stack  is  full. 


3.4  Security  Automata 

We  use  the  example  from  [17]  to  illustrate  how  we  may  enforce  a  security  policy 
that  allows  a  software  agent  to  send  data  to  remote  hosts  (using  method  send) 
as  well  as  read  local  files  (using  method  file_read).  However,  invocations  of 
send  subsequent  to  file_read  are  disallowed.  It  is  difficult,  if  not  impossible, 
to  configure  current  systems  to  enforce  such  a  policy.  For  example,  it  cannot  be 
enforced  in  the  “sandbox”  model  of  Java  [11]  in  which  one  may  either  always 
or  never  allow  access  to  a  system  resource.  As  shown  in  Figure  3,  this  policy  is 
easily  implemented  in  SOL. 
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4  Formal  Semantics 


State  Machines  A  SOL  module  describes  a  state  machine  [6].  A  state  machine 
A1  is  a  quadruple  ( V ,  S,  0,  p),  where  V  =  {vj ,  vo , . . . ,  vn}  is  a  finite  set  of  state 
variables ;  S  is  a  nonempty  set  of  states  where  each  state  s  £  S  maps  each  v  £  V 
to  its  range  of  legal  values;  0:5—^  boolean  is  a  predicate  characterizing  the  set 
of  initial  states ;  p  :  S  x  S  — >  boolean  is  a  predicate  characterizing  the  transition 
relation.  We  write  0  as  a  logical  formula  involving  the  names  of  variables  in  V. 
Predicate  p  relates  the  values  of  the  state  variables  in  a  previous  state  s  £  S  to 
their  values  in  the  current  state  s'  £  S.  We  write  p  as  a  logical  formula  involving 
the  values  of  state  variables  in  the  previous  state  (specified  using  operator  PREV 
or  by  a  when  clause)  and  in  the  current  state. 

SOL  Predicates  Given  a  state  machine  A  =  (V,S,0,p)  we  classify  a  predicate 
p  :  S  — >  boolean  as  a  one-state  predicate  of  A  and  a  predicate  q  :  S  x  S  -A  booleaii 
as  a  two- state  predicate  of  A. 

More  generally,  SOL  predicate  refers  to  either  a  one-state  or  two-state  predi¬ 
cate,  and  SOL  expression  refers  to  logical  formulae  or  terms  containing  references 
to  current  or  previous  values  of  state  variables  in  V. 

Reachability  Given  a  state  machine  A  =  (A,  S,  0,  p),  a  state  s  6  S'  is  reachable 
(denoted  Reachable s(s))  if 

(i)  0(s)  or 

(ii)  3s'  £  S  :  Reachable s(s')  and  p(s',s ) 

Invariants  A  one-state  predicate  p  is  a  state  invariant  of  A  if  and  only  if 

Vs  :  Reachables(s)  =>  pis) 

A  two-state  predicate  q  is  a  transition  invariant  of  A  if  and  only  if 

Vs,  s'  :  (Reachable z(s)  A  p(s,  s'))  =>-  q(s ,  s') 

More  generally,  a  SOL  predicate  x  is  an  invariant  of  A  if  x  is  a  state  invariant 
or  transition  invariant  of  A. 

Verification  For  a  SOL  module  describing  a  state  machine  A,  and  a  set  of  SOL 
predicates  X  =  {xi,X2,  ■  • .  xm},  verification  is  the  process  of  establishing  that 
each  SOL  predicate  x ,  £  X  is  an  invariant  of  A. 


5  SOL  Module 

A  SOL  module  describes  both  an  agent’s  environment,  which  is  usually  non- 
deterministic,  and  the  required  agent  behavior,  which  is  usually  determinis¬ 
tic  [8,12].  Recall  that  for  each  agent  we  distinguish  between  its  monitored 
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variables,  i.e.,  variables  in  its  environment,  and  dependent  variables ,  i.e.,  vari¬ 
ables  whose  values  are  determined  by  the  agent.  Dependent  variables  include 
all  the  controlled  variables  and  internal  variables  of  an  agent  module.  In  the  se¬ 
quel,  we  assume  that  variables  i’i,v-2,  ■  ■  ■  ,i’i  are  an  agent’s  monitored  variables, 
and  that  variables  t>/+i,u/+2,  ■, ■  ,i’n  are  the  agent’s  dependent  variables.  The 
notation  .VC  'In ,  r->, ....  r*,|  is  used  as  an  abbreviation  for  the  SOL  predicate 
(l>!  =  PREV(v ij)  A  (v2  =  PREV(v 2))  A  ...  A  (vk  =  PREV(vk)). 

Components  of  the  state  machine  E  =  (V,  S,0,p )  are  specified  in  the  section 
definitions  of  a  SOL  module.  The  initial  predicate  0  is  specified  in  terms  of 
the  initial  values  for  each  variable  in  V,  i.e.,  as  predicates  9Vl ,  0V2 , . . . ,  0Vn ,  so 
that  0  =  6Vl  A  0V2  A  ...  A  6Vn .  The  transition  relation  p  is  specified  as  a  set 
of  assignments,  one  for  each  dependent  variable  of  E,  i.e.,  as  SOL  predicates 
PvI+1 ,  Pvi+ 2 1  ■  ■  ■  >  Pvn  ,  each  of  which  is  of  the  form: 


'  ei  if  gi 
e2  if  g-i 


\  ek  if  9k 


where  7+1  <i  <  n,  and  e\,e-2,  ■  ■  ■  ,ek  are  SOL  expressions,  and  g\ ,  g-2,  ■  ■  ■ ,  gk  are 
SOL  predicates.  To  avoid  circular  definitions,  we  impose  an  additional  restriction 
on  the  occurrences  of  state  variables  in  these  expressions  as  below: 

Define  dependency  relations  Dnew ,  D0ia ,  and  D  on  V  x  V  as  follows: 

For  variables  v,  and  Vj,  the  pair  (i)i,Vj)  €  Dnew  iff  v j  occurs  outside  a 
PREV ()  clause  in  the  SOL  expression  defining  vp  the  pair  (Vpvj)  G  Dgu 
iff  PREV(vj)  occurs  in  the  SOL  expression  defining  vp  and  D  =  Dnew  U 
D0id-  We  require  Dfew,  the  transitive  closure  of  the  Dnew  relation,  to 
define  a  partial  order. 


5.1  Composing  SOL  Modules 

Consider  two  SOL  modules  describing  the  state  machines  E\  =  (V\ ,  Si ,  0\ ,  p\) 
and  So  =  {V2,  S2,02,  p-i)-  We  define  the  composition  of  the  two  SOL  agents 
E  =  (V,S,0,p)  as  E  =  TiH-Tb  where 

V  =  Vi  U  Do 
0  =  0\  A  0-2 

p  =  p\  A  p-2 

Each  s  €  S  maps  each  v  e  V  to  its  range  of  legal  values 

provided  that  there  is  no  circularity  in  the  occurrences  of  variables  in  p.  Also  by 
assumption,  it  is  the  case  that  p\  and  p-2  define  disjoint  sets  of  state  variables. 


6  Verification 

In  this  section,  we  discuss  how  two  well-known  verification  approaches  may  be 
used  for  establishing  the  invariance  of  predicates  for  a  state  machine  E. 
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6.1  Theorem  Proving 


The  first  approach,  which  uses  induction ,  is  popularly  known  as  theorem  prov¬ 
ing.  Due  to  its  use  of  logical  weakening ,  this  approach  avoids  the  explicit  con¬ 
struction  of  the  state  space  and  the  calculation  of  predicate  Reachable. 


Proof  Rules 

Rule  SINV  Let  p  be  a  one-state  predicate  of  E.  The  following  are  sufficient 
conditions  to  show  that  p  is  an  invariant  of  E,  i.e.,  Vs  :  Reachablea(s)  =>  p(s ): 


SI:  Vs  :  @(s)  =>-  p(s)  and 
S2:Vs,s'  :  (p(s)  A  p(s,  s'))  =>p(s'). 


Rule  TINV  Let  q  be  a  two-state  predicate  of  E.  The  following  are  sufficient 
conditions  to  show  that  q  is  a  transition  invariant  of  E: 


Tl:  Vs,  s'  :  (@(s)  A  p(s,  s'))  =>  q(s,  s') 
T2:Vs,s',s"  :  (q(s,  s')  A  p(s',  s"))  =>(/(s',s") 


Proof:  The  soundness  of  the  above  rules  follows  by  induction  from  the  definition 
of  Reachable. 


Proof  Rules  of  SOLver  We  are  constructing  an  automatic  verification  tool 
SOLver,  based  on  theorem  proving  by  induction,  for  the  verification  of  agent 
properties.  The  proof  rules  we  use  for  verification  are  weaker  forms  of  the  proof 
rules  SINV  and  TINV.  The  tool  SOLver  is  based  upon  our  patented  technology 
developed  in  connection  with  the  formal  verification  tool  Salsa  [9]. 

Rule  SINV-W  Let  p  be  a  one-state  predicate  of  E.  The  following  are  sufficient 
conditions  to  show  that  p  is  an  invariant  of  E: 


51- W:  Vs  :  @(s)  =>-  p(s)  and 

52- W:  Vs,  s'  :  p(s,s')  =^p(s'). 


Proof:  This  is  a  weaker  form  of  SINV. 


Rule  TINV-W  Let  q  be  a  two-state  predicate  of  E.  The  following  is  a  sufficient 
condition  to  show  that  q  is  a  transition  invariant  of  E : 


Tl-W:  Vs,  s'  :  p(s,  s')  =>  q(s,  s') 


Proof:  The  result  follows  directly  from  the  definition  of  transition  invariant. 

6.2  Model  Checking 

In  general,  the  approach  popularly  known  as  model  checking  computes  the  set 
characterized  by  the  predicate  Reachable  either  explicitly  or  implicitly.  Explicit 
state  model  checking  computes  the  set  by  enumerating  each  state  in  the  state 
space.  Symbolic  model  checking  computes  predicate  Reachable  by  symbolic  execu¬ 
tion,  using  a  canonical  representation  (such  as  BDDs)  for  logical  formulae  charac¬ 
terizing  sets  of  states.  One  important  advantage  of  model  checking  over  theorem 
proving  is  its  ability  to  provide  a  counterexample  by  which  we  mean  a  sequence 
of  states  so,  si ,  •  •  • ,  s„_i ,  sn  such  that  0(s o)  and  V(1  <  i  <  n)  :  p(s,:-i ,  s,;),  and 
either  -ix(sn)  (for  a  one-state  predicate  x)  or  -ix(sn-i ,  sn)  (for  a  two-state  pred¬ 
icate  x)  where  x  is  a  presumed  invariant  of  state  machine  E1 .  In  addition  to 
its  limited  applicability  to  finite  state  systems,  a  major  disadvantage  of  model 
checking  is  state  explosion  which  refers  to  the  intractable  complexity  of  the  al¬ 
gorithms  for  computing  predicate  Reachable. 


7  Abstraction 

The  general  idea  behind  abstraction  is  that  in  order  to  verify  the  invariance 
of  a  SOL  predicate  x  for  a  state  machine  E  =  (V,  S, &,p),  one  verifies  instead 
that  x  is  an  invariant  of  a  different  state  machine  Ea  =  ( Va,Sa,@a,Pa )•  We 
say  that  Ea  is  a  sound  abstraction  of  E  relative  to  the  invariance  of  x  if  x  is  an 
invariant  of  Ea  implies  that  x  is  an  invariant  of  E.  We  say  that  E a  is  a  complete 
abstraction  of  E  relative  to  the  invariance  of  x  if  x  is  an  invariant  of  E  implies 
that  x  is  an  invariant  of  Ea ■  If  Ea  is  a  sound  and  complete  abstraction  of  E 
relative  to  the  invariance  of  x,  it  is  also  called  an  exact  abstraction.  In  general, 
the  quotient  system  Ea,  generated  by  an  equivalence  relation  on  S  that  is  a 
bisimulation  on  E,  will  be  exact  for  all  the  invariants  of  E.  For  some  interesting 
methods  that  are  both  sound  and  complete,  we  refer  the  reader  to  [8]. 

The  following  theorems  about  abstraction  are  a  generalization  of  many  of  the 
practical  “abstraction  methods”  used  in  the  verification  of  invariants  for  SCR 
specifications  [8,12], 

1  Theorem  proving  does  provide  some  information,  which  may  be  thought  of  as  a 
“partial  counterexample” ,  upon  proof  failure.  For  example,  when  application  of  the 
proof  rule  SINV  (see  previous  section)  fails,  one  can  usually  extract  information 
about  the  state  or  pair  of  states  for  which  one  of  the  premises  of  the  rule  is  false. 
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7.1  A  Theorem  of  Sound  Abstractions 

Let  S  =  (V,S,0,p)  be  a  state  machine  and  let  Sr  =  (V,S,0a,  Pa)  be  another 
state  machine  constructed  such  that: 

(a)  Vs  €  S  :  0(s)  =>  0a(s),  and 

(b)  Vs,  s'  G  S  :  p{s,  s')  =>  pa (s,  s') 

then  Sr  is  a  sound  abstraction  of  S  with  respect  to  the  invariance  of  any  SOL 
predicate  x ,  i.e.,  if  x  is  an  invariant  of  Sr,  then  x  is  also  an  invariant  of  S. 

Proof:  We  initially  prove  the  following  lemma: 

Lemma  1:  For  state  machines  S  and  Sr  defined  as  above, 

Vs  :  Reachables(s)  =>-  ReachablezR(s)  ■ 

Proof:  Let  s  be  a  state  of  S.  Suppose  s  is  reachable  in  S.  Then,  by  the 
definition  of  Reachable^ ,  0(s)  or  3so,si, . . . ,  s„_i,  s  :  0(sq)  A p(so,  si)  A 
. .  .Ap(s„_i,s).  From  conditions  (a)  and  (b)  above,  and  by  the  definition 
of  ReachablesR,  the  conclusion  follows. 

Case  1:  Suppose  x  is  a  one-state  SOL  predicate.  Since  x  is  a  state  invariant  of 
Sr  (premise),  i.e.,  Vs  :  Reachable sR(s)  x(s),  the  conclusion  follows  from  the 
application  of  Lemma  1. 

Case  2:  Suppose  x  is  a  two-state  SOL  predicate.  Since  x  is  a  transition  invariant 
of  Sr  (premise),  i.e.,  Vs, s'  :  (Reachable er(s)  A  Reachable er(s')  A  pa(s,s'))  => 
q(s,s'),  the  conclusion  follows  from  condition  (b)  above  and  by  the  application 
of  Lemma  1. 

7.2  Quotient  Automata 

Consider  the  state  machine  Sr  =  ( V,S,0a,Pa )•  Let  Va  =  v\,v-2,  ■  ■  -vk  be  the 
set  of  state  variables  whose  names  appear  in  the  logical  formulae2  characterizing 
predicates  @,4  and  pA  •  Each  state  s  G  S  is  an  interpretation  of  the  state  variables 
of  V.  Let  s(fli),  s(v2),  ■  ■  •  s(vk), , . .  s(v„)  denote  the  interpretation  of  variables 
v\,vn,  ■  ■  -  Vu,  ■  ■  -vn  in  state  s.  The  following  equivalence  relation  «  on  S: 

{(si,«2)  I  (s l(l’l)  =  Sn(v  1))  A  (s i(v2)  =  S-2(v-2))  A  .  .  .  (s !(vk)  =  S2(vk))} 

can  be  shown  to  be  a  bisimulation  on  Ljj.  This  follows  from  the  definition  of  a 
bisimulation  relation  -  by  definition,  R  is  a  bisimulation  relation  if  R  progresses 
to  R  itself;  therefore,  since  relation  ss  collapses  all  states  that  are  equal  into 
an  equivalence  class,  transitions  emanating  from  any  state  in  that  set  must  be 
identical.  Therefore  Sa  =  (Va,  Sa ,  0a,  Pa),  the  quotient  automaton  with  respect 
to  the  bisimulation,  whose  state  space  SU  is  the  set  of  equivalence  classes  induced 
by  will  be  a  sound  and  complete  abstraction  of  Sr  for  all  invariants.  Since 
Sr  is  a  sound  abstraction  of  S  relative  to  the  invariance  of  all  SOL  predicates, 
Sa  is  a  sound  abstraction  of  S  for  all  SOL  invariants.  We  call  this  the  General 
Theorem  of  Sound  Abstractions. 

2  We  assume  that  these  formulae  have  been  simplified  to  their  normal  form. 
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7.3  The  SOL  Theorem  of  Sound  Abstractions 

A  corollary  of  the  General  Theorem  of  Sound  Abstractions  is  that  by  establishing 
the  invariance  of  an  SOL  predicate  x  for  any  subset  of  a  collection  of  SOL 
modules,  one  establishes  the  invariance  of  x  for  the  complete  SOL  multi-agent 
system.  The  proof  of  this  follows  from  the  observation  that  the  components 
(corresponding  to  the  dependent  variables)  of  the  initial  predicate  0  and  the 
transition  relation  p  of  the  state  machine  described  by  a  SOL  module  are  specified 
as  a  conjunction  of  predicates,  each  one  corresponding  to  a  dependent  variable  in 
V.  Selection  of  a  subset  of  SOL  definitions  (which  define  the  values  of  dependent 
variables)  amounts  to  “throwing  away”  the  conjuncts  that  correspond  to  the 
variables  whose  definitions  are  being  eliminated.  Therefore,  since 

( . . .  A  0ri+ 1  A  0ri+2  . . .  A  9rje  . . .  A  6Vrl )  =4*  ( . .  •  0ri+1  A  0  ri+ 2  . . .  A  6rk ) 

(.  .  .  A  PrI+ 1  A  PrI+ 2  •  •  •  A  Prh  ...  A  pTrl )  =>  (.  .  .  A  PrI+1  A  PrI+2  •  •  •  A  pTh  ) 

it  follows  from  the  General  Theorem  of  Sound  Abstractions  that  an  invariant  of 
a  reduced  SOL  module  with  dependent  variables  ip+i ,  o , . . . ,  vu  will  also  be  an 
invariant  of  a  SOL  module  with  dependent  variables  rq+i ,  vi+ o , . . .  vu ,  r’/t+i , . . .  vn . 

8  Discussion  and  Related  Work 

SOL  is  based  on  ideas  introduced  in  the  Software  Cost  Reduction  (SCR)  project 
[14, 15]  of  the  Naval  Research  Laboratory  which  dates  back  to  the  late  seventies. 
The  design  of  SOL  was  directly  influenced  by  the  design  of  SAL  (the  SCR  Ab¬ 
stract  Language),  a  specification  language  based  on  the  SCR  Formal  Model  [13]. 
SOL  includes  certain  key  features  of  SAL  including  the  notion  of  events  and  mod¬ 
ularity.  The  notation  of  SCR  has  directly  or  indirectly  influenced  more  recent 
notations  such  as  Reactive  Modules  [4] .  Whereas  the  application  areas  of  Reac¬ 
tive  Modules  are  primarily  hardware  and  communication  protocols,  the  focus  of 
SCR  and  related  languages  has  primarily  been  on  specifying  software  systems. 

Because  of  infinite  or  very  large  state  spaces  of  systems  described  in  SOL, 
finite-state  verification  methods  such  as  that  of  Alur  and  Henzinger  [3]  and  tools 
such  as  Mocha  [2]  are  limited  in  scope.  For  verification  to  succeed,  abstrac¬ 
tion  [12,8]  therefore  plays  a  very  important  role  when  applying  model  checking. 
Although  many  researchers  routinely  apply  abstractions  during  model  check¬ 
ing,  the  abstractions  are  often  applied  in  an  ad-hoc  way  and  are  therefore  not 
always  sound.  In  our  approach,  a  systematic  application  of  abstraction  guar¬ 
antees  soundness  [8].  An  important  advantage  of  model  checkers  is  their  use 
for  refutation  since  the  counterexamples  they  provide  when  a  check  fails  servers 
practitioners  as  a  valuable  debugging  aid  [8] . 

Theorem  proving,  the  only  other  viable  alternative,  has  the  associated  prob¬ 
lems  of  incompleteness  (i.e.,  a  property  that  is  not  provable  may  indeed  be  valid) 
and  lack  of  user  guidance,  along  the  lines  of  counterexamples  provided  by  model 
checkers,  in  case  of  proof  failure.  Also,  “traditional”  theorem  proving  systems 
such  as  PVS  [16]  require  manual  effort  and  mathematical  sophistication  to  use. 
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The  tool  SOLver,  currently  under  development,  is  based  on  the  tool  Salsa  [9] 
which  uses  SAL  as  the  input  language.  Although  a  theorem  prover.  Salsa  affords 
“push-button”  automation,  ease  of  use,  and  counterexample  generation  that  typ¬ 
ify  model  checkers.  The  results  of  our  experiments  with  Salsa  and  a  comparison 
of  its  performance  with  those  of  popular  model  checkers  and  the  theorem  prover 
PVS  are  presented  in  [9].  Since  the  architecture  of  SOLver  is  based  on  Salsa 
(see  [9]  for  details),  and  the  algorithms  of  SOLver  are  extensions  of  those  in 
Salsa,  we  expect  SOLver  to  have  comparable  performance  and  to  possess  similar 
attributes  as  Salsa. 

9  Conclusion 

In  this  paper  we  present  an  integrated  formal  framework  for  the  specification 
and  analysis  of  Multi- Agent  Systems  (MAS).  Our  framework  uses  a  composition 
operator  the  semantics  of  which  are  guaranteed  to  preserve  certain  individual 
agent  properties.  We  demonstrate  that  the  formal  framework  may  serve  as  the 
basis  for  various  analysis  and  transformation  techniques  such  abstraction,  and 
verification  by  model  checking  or  theorem  proving.  We  are  currently  developing 
a  suite  of  analysis  and  transformation  tools  for  SOL  based  on  this  framework. 
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